Drive testing has been used as a method to measure and assess network coverage and capacity for network optimization. Drive testing involves the use of a motor vehicle that moves throughout a wireless coverage area while equipped to record a variety of measurements in a wireless communication network, and/or to submit dummy data to the network so that measurements may be performed by the network.
More recently, so-called “Minimization of Drive Testing” (MDT) efforts have been initiated to minimize such drive testing, as such testing has some inherent inefficiency including fuel consumption and carbon emissions. Additionally, drive testing utilizes dummy data, which is less useful than actual user data. Through MDT efforts, individual mobile stations are used to harvest measurements that would otherwise be obtained or facilitated by a drive tester.
A standardized solution exists for Minimization of Drive Test (MDT) data collection as specified in 3GPP TS 32.422 and related specifications in a cellular system which has a management architecture as shown in FIG. 1 (from 3GPP TS 32.101). MDT is specified for Universal Mobile Telecommunication System (UMTS) and Long Term Evolution (LTE) systems in 3GPP.
The data collection for MDT functions is ordered over the Itf-N interface (see interface number 2 in FIG. 1) from a Network Manager (NM) to a Domain Manager/Element Manager (DM/EM), which in its turn orders the Network Element (NE) to perform the MDT data collection according to the request coming from the NM. The MDT data collection can be ordered from NM using the trace functionality as specified in TS 32.422. The MDT data collection can be ordered for a specific subscriber or terminal, identified by IMSI/IMEI (also called “signaling based MDT trace”) or for a specific area, i.e., set of cells (also called “area based MDT” or “management based trace”).
As some of the data collected during an MDT session may be sensitive from a privacy point of view, a user consent indicator is configured per subscriber in the Horne Subscriber Server (HSS) or Home Location Register (HLR). The user consent indicator is propagated in the signaling control chain (interface 6 in FIG. 1) to the NE (in case of signaling based MDT trace) or via the management interface from DM to the NE (interface 1 in FIG. 1), (in case of management based MDT). The NE carries out the selection of UEs that should participate in the MDT data collection.
When a MDT data collection order (trace order configuration) is received in the NE, it checks for sessions that fulfill the criteria from the MDT order. When such a session is found, the NE checks the user consent indicator for that session. Only if the user consent is set to permit measurements is MDT collection allowed, and the NE starts the MDT data collection for that session.
There are different types of MDT, including the following:
(1) Area based MDT: The MDT order is for a specified area typically for a cell or list of cells.
(2) Signaling based MDT: The MDT order is for a specified user (IMSI) or User Equipment (UE identified by IMEI(SV)).
(3) Logged MDT: The MDT data collection is done for UEs that are in idle mode.
(4) Immediate MDT: The MDT data collection is done for UEs that are in active mode.
Types 1 and 2 are mutually exclusive, as are types 3 and 4. However, type 1 may be combined with type 3 or 4, and similarly type 2 may be combined with type 3 or 4.
There can be several user functions on the NM that uses MDT data collection (e.g., automated functions for finding coverage holes, statistic collection functions, advanced fault localization functions). Some of them make the collected data accessible to 3rd party tools and/or humans.
The current standard solution of user consent and privacy handling for MDT measurement collection is based on the one bit user consent indicator stored as part of subscription data in HSS or HLR. This one bit indicator is sent to the network when the UE establishes connection and it is used by the network to decide whether the given UE is eligible for MDT data collection or not.
The one bit indicator does not allow making any distinction regarding the need for user consent depending on the type of data that is collected, on the use case for which the data is collected, on the differences in operator policy or local regulations in user privacy handling. That is, always the worst case has to be assumed when setting the user consent indicator, i.e., that even privacy sensitive data might be collected (e.g., GPS coordinates). This results in a conservative setting of the user consent indicator, which limits data collection and use cases based on MDT, and limits the value of the user functions built on MDT data.